The present invention relates to a technique suitably adaptable for validation of certificates in public key infrastructure (PKI) environments.
Systems using PKI technologies, including government PKI (GKPI), are becoming more widely used in order to clarify the creator of an electronic document and also to guarantee that such electronic document is free from unauthorized alteration or falsification. In some PKI-based systems, an electronic document is applied digital signature using a key called the secret key, also known as private key, which is exclusively owned by a person who affixes such digital signature, i.e., the signer. Upon reception of the digitally signed electronic document, the signature is validated to make sure that this electronic document is not falsified in any way.
In applications under strict requirements for higher reliability, it is necessary, in order to perform the digital signature validation, to validate the digital signature by means of a public key that is contained in a public key certificate (simply referred to as “certificate” hereinafter) of the signer, which is issued by a certificate authority (CA), and also to check whether a certificate of the signer is a truly valid certificate for an entity or person who validates digital signatures, called the validator. To verify whether the signer's certificate is valid or invalid to the validator, it is required to perform specific processing operations which follow: (1) certification path building, and (2) certification path validation.
In the process of the (1) certification path building, a chain of certificates is established, which is a sequence of trusts of from a CA trusted by the validator, called the trust anchor (TA), up to a CA that has issued the certificate of a signer. This certificate chain is a queue of certificates, wherein the subject entity name of a certificate is identical to the issuer name of another certificate placed next to the certificate, and a key identifier of the subject entity of the certificate matches a key identifier of the issuer of the next certificate. The validator gives access to a repository of each CA for acquiring the certificate, thereby performing the above-stated verification. Especially in a PKI model with CAs of different domains being interconnected together, each of these CAs issues a mutual authentication certificate, called the cross-certificate, to another CA, and vice versa. Accordingly, when building a certification path covering a plurality of different domains, such as in the PKI model, the certificate chain contains therein a cross-certificate(s). Regarding certification path building methodology, a detailed description is found in Section 2 “Certification Path Building” of a document titled “Internet X.509 Public Key Infrastructure: Certification Path Building (RFC4158)”, September 2005, (Relevant Literature #1).
In the above-stated (2) certification path validation processing, an attempt is made to ensure the validity of every certificate of the certificate chain within the certification path that was built by the (1) certification path building processing. To judge whether the certificate is revoked or not, there is used either a certificate revocation list (CRL) to be issued by CA or an online certificate status protocol (OCSP) responder. The validator uses CA certificate to perform the validation of a signature that is added to the CRL obtained by access to the repository of CA. Alternatively, the validator validates a digital signature being added to an OCSP response obtained by sending an OCSP request to OCSP responder, by using a certificate of the OCSP responder. In a case where any certificate is not added thereto, access is provided to the repository of CA to thereby acquire either CA certificate or OCSP responder certificate. Regarding a method of performing the certification path validation, this is discussed in detail in Section 6 “Certification Path Validation” of a document titled “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (RFC5280)” May 2008 (Relevant Literature #2).
Currently available certificate validation models include an end entity model for verification of the validity of a certificate by the validator per se, and a certificate validation server model using a certificate validation server which provides online the certificate validation functionality on behalf of the validator. Specifications of the certificate validation server model are described in “Delegated Path Validation and Delegated Path Discovery Protocol Requirements (RFC3379),” September 2002. (Relevant Literature #3).
When compared to the end entity model, the certificate validation server model offers its advantages which follow. First, it is possible to lessen a client's software program for certificate validation. This can be said because the certificate validation server model is free from the need for mounting on the client the certification path building function for building a certification path(s). Second, merely modifying the setup of the certificate validation server makes it possible to flexibly cope with any possible changes in system configuration because of the fact that the client trusts a decision result of the certificate validation server.
While the certificate validation server builds a certification path and acquires the CRL from CA, once at a time, whenever the certificate validation is performed, this approach is inferior in efficiency. In view of this fact, JP-A-2002-72876 (Relevant Literature #4) discloses therein a technique for speed-up of the certificate validation processing by designing the certificate validation server to register the CRL and/or the certification path.
Additionally, JP-A-2002-163395 (Relevant Literature #5) discloses therein a technique for storing in a cache a certificate validation result obtained using the CRL and/or OCSP responder and for directly using, when it satisfies the server's predefined cache usage criteria, the stored validation result data as a validation result with no changes.